The present invention relates to modeling architectures for modeling electronic systems. More particularly, the present invention relates to architectures for modeling a shared-bus system comprising a plurality of electronic devices interconnected via a shared bus.
One of the more popular ways to interconnect a plurality of electronic devices is through the use of a shared bus. For example, a modern computer network employs a shared bus, such as a SCSI (Small Computer System Interface) bus, to interconnect the CPU with a plurality of devices such as printers, disk drives, scanners, and the like. In a shared bus system, each device on the bus arbitrates for and takes control of the bus whenever it needs to communicate with the CPU and/or another device.
To facilitate discussion, FIG. 1 shows a simplified illustration of a typical shared bus system. In FIG. 1, a shared bus system 100 includes a plurality of devices 102, 104, 106, and 108, which are interconnected via a shared bus 110. Through bus 110, each device may share its resources with another device by exchanging data and commands.
There are times when it may be useful to model a shared bus system, such as shared bus system 100 of FIG. 1. For example, a hardware or software developer working on a prototype device may wish to test the prototype device's interaction with various devices as well as with the shared bus of a shared bus system. Modeling permits the developer to efficiently develop a large number of test cases, each representing a particular behavioral scenario for the shared bus devices, with which the developer can test the prototype device against. Without modeling, the developer would have to physically create a multiplicity of shared bus system configurations and configure each real-world shared bus system to obtain the desired behavior against which the prototype device can be tested. Modeling allows the developer to accomplish the same goal without the expenses and time-consuming efforts of physically creating a multiplicity of real-world systems for the purpose of testing.
In the prior art, modeling engineers have typically tried to mimic as faithfully as possible each constituent part of the system to be modeled. This approach, termed the monolithic modeling approach, attempts to model each constituent device closely after its real-world counterpart. That is, the capability and behavior of each device in the system to be modeled are faithfully recreated in software so that when the various device models are put together, the assembled modeled system would mimic the behavior of its real-world counterpart as faithfully as possible. This modeling paradigm is natural since the modeling itself mimics the way the electronic devices are packaged and sold by the manufacturer, as well as bought and assembled by the user, in the real world.
FIG. 2 illustrates a resultant monolithic system model 200 for the shared bus system 100 of FIG. 1. In FIG. 2, there are shown a plurality of device models 202, 204, 206, and 208 interconnected via a shared bus 216. Each device model includes two modules: a logical module and an I/O specific module. The logic module, such as logic module 202A of device model 202, includes codes and data for modeling behaviors that are invariant with respect to the physical interface through which the device modeled by device model 202 communicates with the outside world. Thus, in a SCSI device, the logic module may contain codes and data for modeling the command handler logic, since SCSI commands are standardized irrespective of the physical interface through which the commands are transmitted. Other logical functions such as how to store and address data, how to handle reset, how to respond to status if inquired, and configuration of non-I/O specific parameters, etc., are also modeled by codes and data in the logical module. The functions performed by the reset handler includes, for example, putting the model into a known state as defined by the SCSI specification following the assertion of SCSI reset on the bus or upon initial power-up. The functions of the command handler includes, for example, processing the commands received from the initiator (e.g., SCSI host) by, for example, validating the fields of the commands and preparing them for the target to process. Configuration of non-I/O specific parameters includes the configuration of non-I/O specific parameters that affect how a device behaves (such as, for example, sense information, contingent allegiance, mode pages, inquiry data, and the like).
The I/O specific module, such as I/O specific module 202B of device model 202, includes codes and data for modeling behaviors that are dependent on the physical interface. For example, interfacing functions specific to a given SCSI implementation are modeled by codes and data in the I/O specific module. Other physical interface-dependent functions and parameters such as the timing information (e.g., communication speed, the synchronous or asynchronous nature of the communication), I/O specific reset handlers, access methods, configuration of I/O specific parameters, and the like, are modeled by codes and data within the I/O specific module. The I/O-specific reset handler resets I/O-specific parameters such as, for example, asynchronous vs. synchronous, single-ended vs. low voltage differential (LVD), narrow vs. wide, single transition vs. dual transition, packetized vs. non-packetized, maximum data transfer rate, and the like. Access methods include, for example, functions for handling asynchronous or synchronous transfer, packetized, data group, SPI-4, and the like. Configuration of I/O specific parameters includes the configuration of such I/O-specific parameters as packetized or non-packetized, quick arbitration and selection (abbreviated QAS), single transition or dual transition, and the like.
FIG. 2 also shows a timing monitor module 212, representing a module for monitoring and validating the timing of the bus cycles. These bus cycles must follow specific parameters laid out by the lower level transport mechanism and protocol in order for the system as a whole to function correctly. Thus timing monitor module 212 monitors the devices to assess, for example, whether the devices output data and commands in a timely manner and whether they respond in a timely manner.
A protocol monitor module 214 monitors transactions at a higher protocol level. For example, protocol monitor module 214 may monitor such protocol-related issues such as data field integrity, transitions between states, the specific SCSI protocol in use, whether the transfer is synchronous or asynchronous, whether the data is packetized or not, and whether dual transition is involved, and the like.
It is observed by the inventor herein, however, that the prior art paradigm of modeling a shared bus system by monolithically modeling each constituent device to faithfully replicate that device's real-world capabilities and behavior and subsequently assembling the individual device models and monitor modules into a modeled system results in inefficiencies in the configuration and management tasks. To facilitate discussion of the shortcomings of the prior art monolithic paradigm, it may be useful to briefly discuss the various tasks that need to be handled in the generation of a typical test case from such a modeled system.
In order to generate a test case from monolithic system model 200, at least two tasks must be performed: 1) configuring the system model 200, and 2) describing the actual commands or transactions that take place with the device models. In the first task, i.e., configuring the system model 200, a plurality of sub-tasks must be undertaken. FIG. 3 is a flowchart illustrating the typical sub-tasks required to configure a monolithic shared bus system model, such as monolithic system model 200.
As shown in FIG. 3, one of the sub-tasks involved in configuring a monolithic shared bus system model is specifying parameters for the device models (302). In this block 302, each device is described to its respective device model. In effect, the sub-task in block 302 represents the description of the internal specifications of a device. If the device is a disk drive connected to a SCSI bus, for example, these parameters in block 302 may include the block size, whether the data is transferred in 8-bit or 16-bit chunks, the transfer speed, the CRC (cyclic redundancy check) interval, the disconnect/reconnect behavior, and the like. These parameters in block 302 may be obtained from the manufacturer of each device or may be approximated by a general model.
In block 304, the parameters for connections between devices are specified to the connected device models. In this block 304, each device model is configured with parameters to specify what it can expect when interacting with another device on the shared bus and how it should behave toward that other device. For example, if the other device is a slower device, the device being configured may be told to communicate only at the maximum speed of the slower device when interacting with the slower device. These parameters need to be specified for each possible connection between any two device models.
In block 306, the parameters for the interactions between each device and the timing monitor module are specified to the timing monitor module. In this block 306, the timing monitor module is configured with parameters to specify what it should expect in terms of timing when interacting with each device model. Thus, the parameters involved may be, for this example, transfer speed, the specific protocol of SCSI in use (since this impacts speed), whether the transfer is synchronous or asynchronous, whether the data is packetized or not, and whether dual transition is involved. As another example, the timing monitor module may monitor set-up and hold time for the various transactions, arbitration time, connect/disconnect time of the devices, and the like. These parameters need to be specified for each possible connection between a device model and the timing monitor module.
In block 308, the parameters for interactions between devices are specified to the timing monitor module. In block 308, the timing monitor module is configured with parameters to specify what it should expect, in terms of timing, when two devices interact. This is similar to programming done in block 304, except that in block 308, these parameters are specified to the timing monitor module. For example, if the one device is a slower device, the timing monitor module may be told to expect the other device to communicate only at the maximum speed of the slower device when the faster device interacts with the slower device. These parameters need to be specified to the timing monitor module for each possible connection between any two device models.
In block 310, the parameters for interactions, at the protocol level, between each device and the protocol monitor module are specified to the protocol monitor module. In block 310, the protocol monitor module is configured with parameters to specify what it should expect, in terms of higher level protocol, when it interacts with a device. This is similar to programming done in block 306, except that in block 306, these parameters are specified at the lower level whereas in block 310, the protocol monitor module is interested in protocol-related transactions between each device and itself. For example, parameters may be configured to tell the protocol monitor module what to expect in terms of configuration and data fields, transitions between states, and the like. Other parameters relevant to protocol integrity issues, such as the specific SCSI protocol in use, such as whether the transfer is synchronous or asynchronous, whether the data is packetized or not, and whether dual transition is involved, and the like, may be specified to the protocol monitor module in block 310 as well. These parameters need to be specified to the protocol monitor module for each possible connection between a device model and itself.
In block 312, the parameters for interactions, at the protocol level, between the devices are specified to the protocol monitor module. In block 312, the protocol monitor module is configured with parameters to specify what it should expect, in terms of higher level protocol, when two devices interact. This is similar to the programming done in block 308, except that in block 308, these parameters are specified at the lower level whereas in block 312, the protocol monitor module is interested in protocol-related transactions between two devices.
As can be appreciated from the discussion above in connection with FIG. 3, the prior art monolithic system model involves many configuration steps to configure data in the various device models as well as in the timing monitor module and in the protocol monitoring module. The numerous configuration steps, some of which involve provisioning repetitive information in multiple device models and modules, disadvantageously increases the management overhead in modeling.
For example, when there are changes to a device model, the new parameters for the changed device model need to be specified in order to create the device model (block 302) and to properly specify connections between that changed device model and other device models (block 304). Some of the same parameters also need to be specified to the timing monitor module so the timing monitor module would know what to expect regarding that changed device model's behavior toward the timing monitor module (block 306) or when that changed device model interacts other device models (block 308).
Further, some of the same parameters also need to be specified to the protocol monitor module so the protocol monitor module would know what to expect regarding that changed device model's behavior toward the protocol monitor module (block 310) or when that changed device model interacts other device models (block 312). Thus, whenever the parameters for a single device model need to be changed, multiple other modules must be reconfigured beside the changed device model. Given the fact that the device models may need to be reconfigured hundreds of times in order to generate the hundreds of test cases required in a typical verification cycle for a new device, the high management overhead associated with the prior art monolithic approach to shared bus system modeling disadvantageously renders the task of generating the required suite of test cases unnecessarily complex, cumbersome, and error-prone.
Furthermore, the replication of some of the parameters of each device model in multiple locations disadvantageously takes up more memory than necessary. Additionally, since each device model stores its own parameters, each device model, the timing monitor module and the protocol monitor module must, during the configuration phase of the modeling software, make function calls to other device models in order to obtain the necessary parameters to configure communication between itself and each of the other device models. With a large number of device models, the total number of function calls can be unduly high and can unduly degrade the performance of the modeling software.
Still further, each device model is implemented, as it is required to do in the real world, with its own logic for monitoring, arbitrating, and selecting the shared bus. With multiple device models running simultaneously, multiple logic modules for performing essentially the same function are executing simultaneously, thereby further unnecessarily degrading the performance of the modeling software.
In view of the foregoing, what is desired is a new architecture for modeling a shared bus system that can accurately furnish the desired modeled behavior while avoiding the disadvantages associated with the prior art monolithic approach for system modeling.